-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Code coverage #25
Code coverage #25
Conversation
Thanks for the contribution! Before we can merge this, we need @invalid-email-address to sign the Salesforce Inc. Contributor License Agreement. |
01d458c
to
6905ee5
Compare
await CommonUtils.executeCommandAsync( | ||
'git config --global user.email "[email protected]"' | ||
); | ||
await CommonUtils.executeCommandAsync( | ||
'git config --global user.name "Your Name"' | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I need to fix this because running these lines changed my git user name and email on my machine.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed it. Checking existence of user name and email first. If they don't error is thrown and try/catch is used to set temporary values.
// @ts-ignore | ||
import * as baseConfig from '@istanbuljs/nyc-config-typescript'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Without @ts-ignore I was getting lint error saying I need to add d.ts
for this module. So suppressing it with @ts-ignore.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have an odd result when I run this from your branch. No matter what Ive tried, it is still picking up two old, non-existent directories, src/landingPage
, and src/messages
, despite git status
showing no differences. I removed the out
and node_modules
dir and rebuilt them, too and recompiled. Really odd and I dont know where this is being picked up from.
I did a fresh checkout and the issue goes away. I wonder where that state is being stored of the old files? |
1 similar comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! If we delete the landingPageCommand.ts which is not being used, coverage will go up. We can always grab it from history when/if we decide to use it.
// @ts-ignore | ||
import * as baseConfig from '@istanbuljs/nyc-config-typescript'; | ||
|
||
const NYC = require('nyc'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any reason not to make this an ES6-style import
here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually tried import
but Typescript compiler would complain I need d.ts
. Then I tried looking for @types/nyc
but it didn't exist so I decided to go with require
.
.github/workflows/run-tests.yml
Outdated
@@ -13,8 +13,33 @@ jobs: | |||
- uses: actions/setup-node@v3 | |||
with: | |||
node-version: ${{ matrix.node }} | |||
- uses: pyvista/setup-headless-display-action@v1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This (and CodeCoverageSummary
, sticky-pull-request-comment
, and setup-headless-display-action
) are likely things we'll need to file 3PPs for, and make our ProdSec reviewers aware of, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Couple things that come to my mind. One is time constraint. Do we want to go through the process of 3PP when we have a milestone to make.
The second is code coverage itself. Do we need it? Or is it a nice-to-have at this point? If we don't need coverage we can only do 3PP for setup-headless-display-action now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm most especially wary of consuming third-party software in GitHub Actions, as there's considerable risk in doing so—those actions by default have the same permissions on your repo as the user who installed them.
I don't feel we should use them without a) good reason, b) proper vetting, and c) robust guardrails to curtail the possibility of security risk.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me check again what salesforcedx does again.
The reason we need it is because runTests
will download/install/launch an instance of VSCode. If we can move our code to be testable with jest we can avoid using runTests
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With regards to launching VSCode, this is something we could do directly. If you look at an example for Azure Pipelines, they stand up an Xvfb server that can host the VSCode process. This is a process we can do in a GitHub Action as well. It's largely what a lot of these 3PP actions are doing behind the scenes.
I'd rather we invest in first-party code specifically for GitHub Actions, because of the risks. To me, if that means things like test runners and code coverage reporting needs to push past V1, in favor of running locally, I'd personally prefer that to rushing into deploying these only to end up with security risks as a result.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm game for leveraging Actions code that comes directly from GitHub/Microsoft (i.e. under https://github.com/actions), because at that point you're trusting the provider that's hosting all of your code and secrets anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me try the Xvfb server sample on Azuer Pipeline now. If this works we can remove setup-headless-display-action .
904b8be
to
c30e833
Compare
Code coverage can now be output with:
npm run test-coverage
Using nyc to instrument the code programatically.
nyc
is CLI of istanbul. Runningnyc
from the command line, likenyc npm run test
, for vscode extension project in Typescript doesn't pickup the behavior defined innyc
's configuration file. So insteadnyc
had to be used programatically. This alleviates from doing a full implementation usingistanbul
APIs to generate code coverage output and then use that output to generate the report.With the code coverage enablement every PR will have % of code covered. This is made possible by an off the shelf GitHub action called Code Coverage Summary. This GitHub action doesn't generate badge for the readme though. I looked around to do that but I think it is probably good for the team to first discuss on that.
Another interesting thing in this PR is the need to use another GitHub action in Setup Headless Display Action. This was needed because VSCode extension test, which calls
runTest
method to initiate the test, will download VSCode, installs that, and then spawns a new instance of VSCode. This fails on CI machine without a monitor attached. Setup Headless Display Action fixes this.